QuickOPC User's Guide and Reference
OPC UA File Transfer
The OPC UA specification (from version 1.02 onwards) allows servers to provide file and directories, resembling traditional file systems, as part of their information model, and QuickOPC allows to consume this functionality comfortably. The detailed description on how this is done follows. For general information about OPC UA File Transfer, see OPC UA File Transfer Concepts.
If you need to make OPC UA File Transfer operations and do not want to write code, or if you just need to experiment with it, you can use the OpcCmd Utility, which has full support necessary. For more information, see Using OpcCmd Utility for OPC UA File Transfer.
QuickOPC gives you multiple ways to use OPC UA File Transfer from your code, and you can pick the one that suits your needs best. The approach used at the lowest level (functionality) is closest to what actually happens in terms of OPC UA specifications; the higher levels provide gradually increased abstractions, shielding you more and more from the OPC UA details of how File Transfer works.
Following API levels are available to you when dealing with OPC UA File Transfer:
You will find more details about the individual levels below. Levels 2 to 3 may require a higher product edition than level 1.
Generally, you should pick one of the API level numerals (1, 2 or 3), and perform all your OPC UA file transfer operations within that level. Combining multiple levels, if necessary, is possible, but is considered a sub-optimal design.
We recommend that you find and use the highest level possible for your task, because it is usually the easiest one to work with, and gives the shortest code. Start with level 3, and adopt lower levels only if you find something that cannot be done on the higher level.
This is the "brute force" approach to OPC UA File Transfer: your code uses the EasyUAClient object to interrogate the information model and make OPC UA methods calls for File Transfer operations. When using this API level, you need to carefully study the OPC specifications in order to call the right methods, provide them with proper arguments, and interpret the results correctly. You can control precisely what happens, but the resulting code tends to be relatively complicated and unnecessarily long. You also need to be very careful about not making mistakes such as forgetting to close an OPC UA file handle.
There is no specific reference documentation to this API level in QuickOPC, because the normal means available on the EasyUAClient object (such as reading node attributes, browsing, or method calls) are used. You need to consult the OPC UA specification for information about the OPC UA File Transfer model, the objects and types involved, their relations, and the properties and methods they have. Also note that "goodies" and optimizations provided by higher levels (described in OPC UA File Transfer internals) are not available in this API level.
As for several other OPC UA functionality areas, QuickOPC provides a specialized client object that makes it easier to develop client programs. For OPC UA File Transfer, you can use the specialized EasyUAFileTransferClient object. The advantage over API level 1 is that you do not have study the OPC UA specifications and write low-level code to make each method call; all this knowledge is already encapsulated in the specialized client object for you. For example, you can directly call methods such as OpenFile or ReadFile, without having to know what they need to do internally.
See OPC UA File Transfer Client for more information on this approach.
When you are using API level 2, there is no reason why not to combine it with level 2+ or 2++, if needed.
This API level adds .NET extension methods to the IEasyUAFileTransfer interface, which allows you to perform more complex File Transfer tasks with short code. For example, extension methods are available for easier browsing, easier navigation among file and directory nodes, object creation and deletion, and moving and copying files and directories.
When you are using API level 2+, there is no reason why not to combine it with level 2 or 2++, if needed.
While accessing the file data using the specialized File Transfer client object is convenient, the actual properties and methods used are still specific to this object. To overcome this, QuickOPC allows you to manipulate OPC UA file data using Stream abstraction, which is well-defined and broadly used in Microsoft .NET. The API level 2++ provides the methods that allow you to open or create .NET streams on OPC UA files, and the actual stream implementations for OPC UA.
See OPC UA File Streams for more information on this approach.
When you are using API level 2++, there is no reason why not to combine it with level 2 or 2+, if needed.
With the File Provider Model, not only are the operations on file data (contents) generalized, but also the operations on the file system itself, such as navigation between directories and files, creating and deleting files and directories, etc. The File Provider Model allows you to work with OPC UA file system in the same way as with the physical file system, and other file systems for which the file providers are available (such as file providers for embedded resources) from Microsoft or other parties.
See File Provider Model in OPC UA for more information on this approach.
For accessing the actual file data, the File Provider uses the Stream abstraction, analogous to API Level 2++, differing only in the methods that you use to obtain the data streams. Once your code has obtained the stream object for a particular OPC UA file, it can work with it as with any other data stream.
When using the File Provider model, once you obtain the initial object, you "lose" the relation of the file and directories you work to the OPC UA information model: You cannot easily determine the node Ids of file and directory objects you work with, and use them subsequently. This is usually not a problem, but if your application requires it, you should consider using a lower API level.